A simple user-facing application, such as a stock-quote application or a bank-balance inquiry application, invokes a service and waits on the response. The network or the middleware layer ensures that the response returns to the invoking client. Multiple requests from a client usually happen in a synchronous fashion. As a result, the behavior of these applications can be observed by following the sequence of messages that make up the control flow. This model can be extended to cover business logic executing in a middleware environment as long as it holds to the limitation of executing a session in a single thread. As used herein, application-based systems that exchange messages between modules or components are generally referred to as “messaging systems.”
However, more complex business functions are often constructed in a more loosely coupled fashion. This may mean that requests are submitted to modules of the application without waiting on an immediate response. Responsibility for a process may be handed off from one module of the application to another, or to an entirely different application. We refer to applications of this type as composite business applications. Further, we use the term “conversation” to refer to a sequence of messages that is related to a particular goal, for example, a business goal.
Where a simple application waits for the completion of a request before continuing, a request in a composite business application may be executed asynchronously, relying on a call-back mechanism or polling in order to determine its eventual outcome. This more complex pattern of interaction places a greater burden on the application modules to keep track of the state of multiple conversations and to route a message to its correct destination. It is common practice to include application specific data in the messages that are exchanged so that they can carry necessary context from one module to another. The context data may include a data element that serves as a conversation identifier for the application modules that are involved. Recent standards such as WS-addressing (M. Gudgin et al., “Web Services Addressing 1.0—Core” available from: http://www.w3.org/TR/ws-addr-core/) proposes to let business application developers delegate this task to the middleware level rather than crafting application-specific solutions. Yet, for most existing applications and for composite business applications that span multiple domains of control, the current practice of using application-specific conversation identifiers continues to be in effect.
The increasing complexity of business applications poses new challenges for understanding application behavior and requires new tools for problem determination. In the absence of standards-based approaches such as WS-addressing, it may be difficult to discover conversation identifiers from trace information, especially without the help of the original developer or documentation.
Traditional correlation mechanisms such as ARM (“Application Response Measurement” available from: http://www.open group.org/tech/management/arm/) provide an API (Application Programming Interface) that the application can call to record control flow in a distributed environment. Tools such as the Web Services Navigator (W. De Pauw et al., “Web Services Navigator: Visualizing the Execution of Web Services,” IBM Systems Journal, Vol. 44, pp. 821-846, 2005) or the Eclipse Test & Performance Tools Platform (TPTP) (“The Eclipse Test & Performance Tools Platform,” Available from: http://www.eclipse.org/tptp/) visualize the control flow of messages in composite applications. However, such tools can only combine messages that appear in a direct calling sequence and fail to combine groups of messages that constitute business process conversations. For example, one application may put the result of a transaction in a database, so that it can be picked up by another application. In traditional tools, this would show up as an interruption in the control flow where the information is temporarily stored in the database.
Accordingly, what is needed is an improved technique for flow analysis in messaging systems.